CEP for the OCI storage of conda packages & repodata #70

wolfv · 2024-04-12T14:35:59Z

Fill in the technical details of the OCI registry storage for reference.

wolfv · 2024-04-12T14:38:09Z

we should link refernce impls.
we should say that conda / mamba / rattler use oci:// as the scheme.

cep-oci.md

jaimergp · 2024-04-12T14:46:27Z

cep-oci.md

+
+A conda package, in an OCI registry, should ship up to 3 layers:
+
+- The package itself, as a tarball. (mandatory)


You mean the contents of the package, or the compressed artifact (tarball or not)? In .conda the outer layer is actually a ZIP file, and the inner ones are zstd tarballs. Would be helpful to clarify.

Right, should leave the tarball out of the sentence. It's the package data itself.

Also, some artifacts in defaults are available both as .tar.bz2 and .conda. Should we restrict one package layer for each label? I don't think we need to.

Everything would work fine if there are two layers, they should just not have the same mediaType.

cep-oci.md

jaimergp · 2024-04-12T14:49:12Z

cep-oci.md

+
+For example, a package like `xtensor-0.10.4-h431234.conda` would map to a OCI registry `conda-forge/linux-64/xtensor:0.10.4-h431234`.
+
+### Layers


A table with the different layer mediaTypes and the expected contents would make this section super easy to read.

Feel free to format and push to this PR! :) This is a collaborative document

jaimergp · 2024-04-12T14:56:49Z

we should say that conda / mamba / rattler use oci:// as the scheme.

What does a oci:// URL look like? Is it a direct translation of the anaconda.org artifact that gets manipulated? How is the server referred to? Basically, which one is correct:

oci://ghcr.io/channel-mirrors/conda-forge/linux-64/xtensor:0.10.4-h431234
oci://ghcr.io/channel-mirrors/conda-forge/linux-64/xtensor-0.10.4-h431234
oci://ghcr.io/channel-mirrors/conda-forge/linux-64/xtensor-0.10.4-h431234.tar.bz2

Is it possible to refer to a layer directly by URL? In case of repodata:

oci://ghcr.io/channel-mirrors/conda-forge/linux-64/repodata.json.zstd
oci://ghcr.io/channel-mirrors/conda-forge/linux-64/repodata.json:zstd

I think this needs to be standardized too.

jaimergp · 2024-04-12T14:58:21Z

cep-oci.md

+
+We want to use OCI registries as a storage for conda packages. This CEP specifies how we lay out conda packages on an OCI registry.
+
+## Specification


The distribution-spec contains useful definitions for these terms:

https://github.com/opencontainers/distribution-spec/blob/v1.0/spec.md#definitions

I linked it :)

jaimergp · 2024-04-12T15:04:28Z

cep-oci.md

+
+- for a .tar.bz2 package, the mediaType is `application/vnd.conda.package.v1`
+- for a .conda package, the mediaType is `application/vnd.conda.package.v2`
+- for the `info` folder as gzip the mediaType is `application/vnd.conda.info.v1.tar+gzip`


The info folder can get heavy with licenses, test files and what not. Will we allow .tar+zstd, for example?

Since we currently have uploaded the whole conda-forge with the gzip one, I would suggest to keep it like that for now. We could move to a zstd encoded one in the future.

Or we could just allow for any encoding (+gzip or +zstd)?

It would be nice to be able to use the unmodified info-pip-23.3.1-py312haa95532_0.tar.zst out of the .conda

Indeed. I used the tar.gz approach because of how easy it is to open and explore it with pure Python. But the unmodified one makes sense as well. WE could specify that application/vnd.conda.info.v1.tar+zst will also be accepted?

Makes sense.
.tar.gz just seemed odd although gzip is very ordinary it hasn't been used in conda packaging.

Co-authored-by: Matthew R. Becker <[email protected]>

Co-authored-by: jaimergp <[email protected]>

wolfv · 2024-04-12T15:56:20Z

Yeah, the nice thing is that the URLs map directly to the OCI registry. There just needs to be some post-processing for the tags.

E.g. instead of

https://conda.anaconda.org/conda-forge/linux-64/repodata.json

We ask for

oci://ghcr.io/channel-mirrors/conda-forge/linux-64/repodata.json:latest

And for packages

https://conda.anaconda.org/conda-forge/linux-64/numpy-1.23.1-h123123.tar.bz2

We ask for

oci://ghcr.io/channel-mirrors/conda-forge/linux-64/numpy:1.23.1-h123123

wolfv · 2024-04-12T16:05:07Z

One thing that also needs to go into this document is how tags are formatted. Some versions cannot be translated to tags directly because of the rules of OCI registries.

The functions are here:

https://github.com/mamba-org/rattler/blob/a2073aa6b92196c50208d39fc6b6c67469bf7810/crates/rattler_networking/src/oci_middleware.rs#L77-L92

And when a package name starts with _ (also illegal on OCI registry) then we map it to _ -> zzz: https://github.com/mamba-org/rattler/blob/a2073aa6b92196c50208d39fc6b6c67469bf7810/crates/rattler_networking/src/oci_middleware.rs#L158-L161

jaimergp · 2024-04-12T16:09:41Z

Food for thought: implement subdirs with platform metadata per layer.

jaimergp · 2024-04-12T16:17:52Z

Some versions cannot be translated to tags directly because of the rules of OCI registries.

For reference, rules are here: https://github.com/opencontainers/distribution-spec/blob/v1.0/spec.md#pulling-manifests

Hind-M · 2024-04-15T09:15:18Z

* we should say that conda / mamba / rattler use `oci://` as the scheme.

Hmm, AFAIK we are rather using https as scheme in mamba: https://ghcr.io/...
Last time I checked, I think curl was complaining about unknown oci protocol...

wolfv · 2024-04-15T09:53:06Z

Yeah, but regular HTTPs requests don't work. That's why we need a middleware or some other layer that converts oci://... requests to https:// before sending them to cURL.

Co-authored-by: jaimergp <[email protected]>

cep-oci.md

Hind-M · 2024-06-03T15:20:31Z

Added a commit but couldn't push it here.

wolfv · 2024-06-03T15:47:34Z

Looks good, @Hind-M. Maybe you can make a PR against my branch (https://github.com/wolfv/ceps/tree/oci-cep). I can then merge it there, and the PR will be updated.

Hind-M · 2024-08-07T09:17:19Z

The rendered version for convenience: https://github.com/wolfv/ceps/blob/oci-cep/cep-oci.md

beckermr

One question.

beckermr · 2024-08-07T11:24:16Z

cep-oci.md

+#### Implementation (conda / mamba / rattler)
+
+##### mamba
+
+In order to fetch packages from an OCI registry, we need to set a mirror (can be more than one) for the channel to be used (e.g `conda-forge`).
+This can be done in the rc file as follows:
+
+```
+mirrored_channels:
+  conda-forge: ["oci://ghcr.io/channel-mirrors/conda-forge"]
+```
+
+When a user requests installing a package (with the configuration set above, and using `conda-forge` channel), a set of requests to fetch `repodata.json` are first performed as follows:


Why are we marking these as mirrored instead making them first-class things via using the normal channels config setting with an oci:// prefix to mark OCI channels?

I believe this is orthogonal - you should be able to use the oci:// URL as your only channel as well.

Then why do we need the mirrored_channels option at all?

Maybe not in this CEP? Specifying how we expect channel mirroring works could have merits. Specifically, we should define where the repodata.json file comes from when we have multiple mirrors.

Ideally we would also define how we combine download counts from multiple mirrors (but all that would definitely belong into a different CEP).

Yeah we should handle mirroring in another CEP I would think.

Yes it's orthogonal. I changed it to not mention mirrors anymore.

Hind-M · 2024-08-19T11:58:25Z

jezdez · 2024-08-19T21:31:42Z

cep-oci.md

+<table>
+<tr><td> Title </td><td> OCI registries as conda channels </td>
+<tr><td> Status </td><td> Proposed </td></tr>
+<tr><td> Author(s) </td><td> Wolf Vollprecht &lt;[email protected]&gt;</td></tr>


@Hind-M Could you please add yourself to the author list?

jezdez · 2024-08-19T21:37:45Z

cep-oci.md

+For `jlap`, the following mediaType is used:
+
+- `application/vnd.conda.jlap.v1`
+
+The `jlap` file should also be stored under the `<channel>/<subdir>/repodata.json` path as an additional layer.


Since the JLAP proposal has not been accepted, and sharded repodata approved instead, it may not be needed to keep this in here.

jezdez · 2024-08-19T21:39:00Z

cep-oci.md

+> [!NOTE]
+> **Package names in the conda world**
+> 
+> The following regex is given by [`conda/schemas`](https://github.com/conda/schemas/blob/473708ac97283708d6664cbd89b8049ad1623489/common-1.schema.json#L58-L82) for a valid package name: `^[a-z0-9_](?!_)[._-]?([a-z0-9]+(\.|-|_|$))*$`


It would be good to not rely on conda/schema alone, and verify with the conda code base about the regex, in case the schema isn't up-to-date.

All of these schemas are probably wrong in some way.

jezdez · 2024-08-19T21:55:17Z

cep-oci.md

+
+The regex expresses that names can only start with an alphanumeric letter.
+
+In `conda`, names can start with an underscore and it is used by conda-forge (e.g. `_libgcc_mutex`). For this reason, we prepend packages with a leading underscore with the string `zzz`. The name would thus be changed to `zzz_libgcc_mutex`.


Suggested change

In `conda`, names can start with an underscore and it is used by conda-forge (e.g. `_libgcc_mutex`). For this reason, we prepend packages with a leading underscore with the string `zzz`. The name would thus be changed to `zzz_libgcc_mutex`.

In `conda`, names can start with an underscore and it is used by conda-forge (e.g. `_libgcc_mutex`). For this reason, we prepend packages with a leading underscore with the string `internal`. The name would thus be changed to `internal_libgcc_mutex`.

internal seems more fitting than zzz 💤

I'm afraid we might be late here. ~74 packages are mirrored like this already. We would need to delete and re-mirror? Or can can we just copy images and labels?

Also, how can we safely remove internal_ from the names? It might be something being used already. What about internal___ (triple underscore)?

See my comment below on making this not ambiguous by merging this part of the spec with other encodings.

I'm afraid we might be late here. ~74 packages are mirrored like this already. We would need to delete and re-mirror? Or can can we just copy images and labels?

The mirrors are proofs of concept from the conda community's perspective (I think from conda-forge as well), so I don't think these matter. Re-mirroring 74 packages seems a small price to pay for a better spec.

100% agreed @jezdez readding 74 packages is simple enough.

jezdez · 2024-08-19T21:56:24Z

cep-oci.md

+- `+` is replaced by `__p__`
+- `!` is replaced by `__e__`
+- `=` is replaced by `__eq__`


That list seems to be a little random, it looks like Python dunder methods, but not quite valid, how about this instead?

Suggested change

- `+` is replaced by `__p__`

- `!` is replaced by `__e__`

- `=` is replaced by `__eq__`

- `+` is replaced by `__add__`

- `!` is replaced by `__not__`

- `=` is replaced by `__eq__`

p for plus and e for exclamation, I guess? These characters might not mean "adding" or "negating" in a version/build string, so I'm not sure whether this is a good way to solve the "randomness" here. These names are only for the OCI names, anyway, right? They are renamed once downloaded.

p for plus and e for exclamation, I guess?

Yes!
These mappings (prepending the package names starting with _ with zzz and replacing + etc for tags) are really only intended to make them valid in order to be stored in an OCI registry (correct me if I'm wrong @wolfv). It doesn't impact anything elsewhere as the names and tags are still visible (by users when downloaded for example) as their original strings.
So I don't think having internal instead of zzz (same for the tags suggestions) would really matter (apart from making sure that it wouldn't conflict with potential similar existing strings).
While something more explicit would be preferable, given that a bunch of packages have already been mirrored that way as @jaimergp mentioned, I would say to keep it as is?

Is there a standard encoding scheme we can rely on here instead of inventing our own?

Also, if we insist of a special encoding, we can add underscores themselves as __under__, which would render our scheme unambiguous, since an existing package with __under__ in it would be mapped to __under____under__under__under____under__.

Are conda package names case sensitive?

Based on your findings do you want to change anything with regard to the name mangling suggested above?

Conda package names are always lower case, so presumably case insensitive.

@baszalmstra we might as well have everything lowercase since that is what the OCI registry will look like.

Case insensitive filesystems are usually case preserving though.

jaimergp · 2024-08-20T10:56:38Z

cep-oci.md

+
+A given conda-package is identified by a URL like `<subdir>/<package-name>-<version>-<build>.<ext>` where `<subdir>` is the platform and architecture, `<package-name>` is the name of the package, `<version>` is the version of the package, `<build>` is the build string of the package, and `<ext>` is the extension of the package file.
+
+#### Mapping the package name


Are these "mappings" reverted to their original names once downloaded/extracted? I would assume so and I think that should be part of the CEP.

I added a note for that.

-Add me as author -Remove jlap as not relevant anymore

beckermr · 2024-08-20T14:07:45Z

I am emeritus so I cannot vote here, but IMHO the issues around encoding/decoding above need to be resolved before this spec can be passed.

jakirkham · 2024-08-20T21:13:27Z

It seems like there is a fair amount of discussion still happening here for an active vote. Should we cancel the vote and reschedule after that discussion has reached a conclusion?

baszalmstra · 2024-08-21T07:21:42Z

cep-oci.md

+
+The regex expresses that names can only start with an alphanumeric letter.
+
+In `conda`, names can start with an underscore and it is used by conda-forge (e.g. `_libgcc_mutex`). For this reason, we prepend packages with a leading underscore with the string `zzz`. The name would thus be changed to `zzz_libgcc_mutex`.


What happens if there is also a package called zzz_libgcc_mutex?

This seems like a possible attack vector.

This is similar to symbol name mangling I guess? Perhaps we should prefix all packages with a common prefix and a special one for underscores?

baszalmstra · 2024-08-21T07:28:56Z

cep-oci.md

+- `+` is replaced by `__p__`
+- `!` is replaced by `__e__`
+- `=` is replaced by `__eq__`


Is there a standard encoding scheme we can rely on here instead of inventing our own?

The text itself mentiones that package names can start with an underscore. _libgcc_mutex is the example given.

Perhaps we can learn from symbol name mangling instead of coming up with a unique scheme?

Hind-M · 2024-08-21T15:37:06Z

It seems like there is a fair amount of discussion still happening here for an active vote. Should we cancel the vote and reschedule after that discussion has reached a conclusion?

I think we can wait and see if we reach a conclusion before the voting deadline, and possibly extend it if necessary. If not, we would definitely reschedule yes.
I'm not familiar with the usual processes (of voting and such), so if this isn't the correct approach, please let me know and I'll adjust accordingly.

jaimergp · 2024-08-27T14:18:30Z

This is similar to symbol name mangling I guess? Perhaps we should prefix all packages with a common prefix and a special one for underscores?

I like this proposal by @baszalmstra, but we will need to remirror the whole thing.

Another alternative, as proposed by @wolfv, is to SHA256 encode the names and forget about it. You can map back by checking the internal metadata. This will also require a complete remirror.

But we can also simply SHA256 encode the name of container images that start with an underscore and leave everything else untouched. This wouldn't require a full remirror.

beckermr · 2024-08-27T14:36:59Z

I think the name length limit is the bigger issue here though. I guess we'll need a fixed length hash of the name.

wolfv · 2024-08-27T14:57:42Z

Let me clarify some things:

Name attacks are not really possible (for now) since we also mirror the repodata from conda-forge / Anaconda.org. From the repodata, we just use the SHA256 hash to directly reference the right blob. The names & tags for the individual packages are mainly "cosmetic".

Even if we would run our own indexing, we would refer back to the stored index.json file (and the name in there) and not derive back the original name from the OCI image.
So I am personally not super concerned by this.

But I can sympathize with a mapping that would disallow any such overlaps.

I also think that re-mirroring might not be a big issue, since we just need to move the names / tags in the OCI registry to the right places (SHA hashes and packages will stay the same).

Hind-M · 2024-08-28T15:35:04Z

So just to wrap up here:

Since we are constrained by the limit of characters, we could say that we should avoid mapping every underscore.
The names should be easily identifiable by users (useful when searching for packages in the registry), so using a hash instead of the name would be cryptic.
Appending the name hash or a part of it sounds weird (and somehow redundant?) - even if we do that for every package to be consistent (not only the ones starting with an underscore), but we still can.
Prepending a few characters like the first strategy (zzz) seems to be a good compromise.
Maybe use something else instead like @jezdez suggested? (pkg, oci, int (for internal)...)
I have a preference for oci, since it's suggesting that this is an oci specific thing.
We can do this for all packages or just for the package names starting with _.

Should we think of handling exceeding the max limit of characters as well? (I'm not sure if this is something already taken care of).

beckermr · 2024-08-28T15:45:54Z

We CANNOT only prepend to packages that start with an underscore. This would declare part of the package namespace off limits for all conda users. That action requires at minimum a separate CEP where we codify package names formally. We have to preprend to everything.

And yes we need to handle the max characters limit properly in this CEP.

dholth · 2024-08-28T16:50:17Z

Where is the specification for the length limit?
Do users have business browsing through the raw OCI anyway?

beckermr · 2024-08-28T17:10:56Z

Tags have a limit of 128 characters: https://docs.docker.com/reference/cli/docker/image/tag/
Names have practical limits. See the implementers note in the OCI spec for pull: https://github.com/opencontainers/distribution-spec/blob/main/spec.md#pull.

It is hard to know if people want to browse an OCI registry. For sure github provides searches based on image names. See for example the existing OCI mirror (https://github.com/orgs/channel-mirrors/packages) based on a beta spec.

Hind-M · 2024-09-03T08:57:45Z

FYI, and considering the still ongoing discussions, the vote has been postponed to a later date that is yet to be determined.

OCI cep

438598e

beckermr reviewed Apr 12, 2024

View reviewed changes

cep-oci.md Outdated Show resolved Hide resolved

jaimergp reviewed Apr 12, 2024

View reviewed changes

cep-oci.md Outdated Show resolved Hide resolved

beckermr reviewed Apr 12, 2024

View reviewed changes

cep-oci.md Outdated Show resolved Hide resolved

jaimergp reviewed Apr 12, 2024

View reviewed changes

cep-oci.md Outdated Show resolved Hide resolved

jaimergp reviewed Apr 12, 2024

View reviewed changes

cep-oci.md Outdated Show resolved Hide resolved

jaimergp reviewed Apr 12, 2024

View reviewed changes

wolfv and others added 2 commits April 12, 2024 17:50

Update cep-oci.md

5e3daed

Co-authored-by: Matthew R. Becker <[email protected]>

Update cep-oci.md

ea109b7

Co-authored-by: jaimergp <[email protected]>

jaimergp linked an issue Apr 15, 2024 that may be closed by this pull request

CEP request: OCI packaging #69

Open

wolfv and others added 2 commits April 25, 2024 16:06

Update cep-oci.md

0416a33

Co-authored-by: jaimergp <[email protected]>

add some details for the oci <-> conda mapping

e8f19c1

jaimergp mentioned this pull request Apr 30, 2024

Add OCI registry support in conda/mamba Quansight-Labs/czi-conda-forge-mgmt#24

Open

wolfv added 2 commits May 1, 2024 08:38

add some more info

9bb27ea

Update note formatting and add link

6ee85fa

wolfv commented May 4, 2024

View reviewed changes

cep-oci.md Outdated Show resolved Hide resolved

Add more info (mediaTypes, implementation...)

d339ca0

Comply with ceps template

8cdc5f2

beckermr requested changes Aug 7, 2024

View reviewed changes

Remove mentioning mirrors

5c88967

jezdez added the vote Voting following governance policy label Aug 19, 2024

jezdez reviewed Aug 19, 2024

View reviewed changes

jezdez mentioned this pull request Aug 19, 2024

Add Conda Ecosystem Explained article. conda/conda-dot-org#198

Merged

jaimergp reviewed Aug 20, 2024

View reviewed changes

Review:

193259a

-Add me as author -Remove jlap as not relevant anymore

Hind-M force-pushed the oci-cep branch from 9be8877 to 02b6f3d Compare August 20, 2024 13:56

Add important note regarding the mapping of package names and tags

6e6cd7d

Hind-M force-pushed the oci-cep branch from 02b6f3d to 6e6cd7d Compare August 20, 2024 13:59

baszalmstra reviewed Aug 21, 2024

View reviewed changes

baszalmstra mentioned this pull request Sep 3, 2024

Support for GCS private conda registry. prefix-dev/pixi#1922

Closed


		A conda package, in an OCI registry, should ship up to 3 layers:

		- The package itself, as a tarball. (mandatory)


		For example, a package like `xtensor-0.10.4-h431234.conda` would map to a OCI registry `conda-forge/linux-64/xtensor:0.10.4-h431234`.

		### Layers


		We want to use OCI registries as a storage for conda packages. This CEP specifies how we lay out conda packages on an OCI registry.

		## Specification


		The regex expresses that names can only start with an alphanumeric letter.

		In `conda`, names can start with an underscore and it is used by conda-forge (e.g. `_libgcc_mutex`). For this reason, we prepend packages with a leading underscore with the string `zzz`. The name would thus be changed to `zzz_libgcc_mutex`.


		A given conda-package is identified by a URL like `<subdir>/<package-name>-<version>-<build>.<ext>` where `<subdir>` is the platform and architecture, `<package-name>` is the name of the package, `<version>` is the version of the package, `<build>` is the build string of the package, and `<ext>` is the extension of the package file.

		#### Mapping the package name

CEP for the OCI storage of conda packages & repodata #70

Are you sure you want to change the base?

CEP for the OCI storage of conda packages & repodata #70

Conversation

wolfv commented Apr 12, 2024

wolfv commented Apr 12, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jaimergp commented Apr 12, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wolfv commented Apr 12, 2024

wolfv commented Apr 12, 2024 • edited Loading

jaimergp commented Apr 12, 2024

jaimergp commented Apr 12, 2024

Hind-M commented Apr 15, 2024

wolfv commented Apr 15, 2024

Hind-M commented Jun 3, 2024

wolfv commented Jun 3, 2024

Hind-M commented Aug 7, 2024

beckermr left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Hind-M commented Aug 19, 2024 • edited by jezdez Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jezdez Aug 20, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Hind-M Aug 20, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

beckermr Aug 20, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

beckermr commented Aug 20, 2024

jakirkham commented Aug 20, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Hind-M commented Aug 21, 2024

jaimergp commented Aug 27, 2024 • edited Loading

beckermr commented Aug 27, 2024

wolfv commented Aug 27, 2024

Hind-M commented Aug 28, 2024

beckermr commented Aug 28, 2024 • edited Loading

dholth commented Aug 28, 2024

beckermr commented Aug 28, 2024 • edited Loading

Hind-M commented Sep 3, 2024

wolfv commented Apr 12, 2024 •

edited

Loading

Hind-M commented Aug 19, 2024 •

edited by jezdez

Loading

jezdez Aug 20, 2024 •

edited

Loading

Hind-M Aug 20, 2024 •

edited

Loading

beckermr Aug 20, 2024 •

edited

Loading

jaimergp commented Aug 27, 2024 •

edited

Loading

beckermr commented Aug 28, 2024 •

edited

Loading

beckermr commented Aug 28, 2024 •

edited

Loading